Is it good to create service whih use _eval?

Hi,

we integrate different products in our solution like ARAS, Doors 9.5, RTC etc. in some of the systems for example in Aras when you want to create new Object you construct Aras-like xml and send it to Aras and the system creates the Object.

So my idea is to use this approach in Door 9.5. So in my application(java based) to construct the dxl script for  example for updating,deleting, creating and to send to open Doors Service. Which just to take the dxl and to evaluate it.

So my idea is to remove all the complex/different dxl services and to make one service which takes dxl . In Java I can easy parse XML, JSON and make complex operations.

 

So is it a good idea to try to do that to generate the dxl in my application and to make Doors 9.5 just to _eval it.

 

What are the restrictions of the _eval function in DXL?

 


Dinio - Tue Jul 12 08:30:43 EDT 2016

Re: Is it good to create service whih use _eval?
Mathias Mamsch - Tue Jul 12 13:05:53 EDT 2016

There is nothing to say against using eval_ ... In the ends it is like running a DXL script. Still with an architecture you describe there a quite a lot of pitfalls to overcome. So I would recommend to look for a commercial Java Backend for DOORS (like Sodius MD Workbench). I would be open to contribute to an open source DOORS Server Backend, as long as the project is driven by someone else (I really cannot find the time to actively drive such a project). 

Regards, Mathias

Re: Is it good to create service whih use _eval?
Dinio - Wed Jul 13 01:48:52 EDT 2016

Yes,@Mathias

there are a lot of pitfalls but our client does might not want to use Sodius because of the license policy.($$$) But I am wondering what is the power of this Sodius can it read tables, OLE objects etc.?

Using such eval_ compatible service will help us in a lot of cases , but we can still rely on old Doors services with installation scripts on the Backend and so on , as well as OSLC services which has a lot of bugs and make their usage hard.

So, @Mathias Mamsch ad07d6e1-5bea-4d69-8513-47a3d3c94573 you said that sing eval_ function is not a bad idea?​

PS.

Is this the Doors Server backend project?

https://github.com/domoran/DriveDOORS

 

Re: Is it good to create service whih use _eval?
DOORSHAM - Wed Jul 13 05:25:10 EDT 2016

Dinio - Wed Jul 13 01:48:52 EDT 2016

Yes,@Mathias

there are a lot of pitfalls but our client does might not want to use Sodius because of the license policy.($$$) But I am wondering what is the power of this Sodius can it read tables, OLE objects etc.?

Using such eval_ compatible service will help us in a lot of cases , but we can still rely on old Doors services with installation scripts on the Backend and so on , as well as OSLC services which has a lot of bugs and make their usage hard.

So, @Mathias Mamsch ad07d6e1-5bea-4d69-8513-47a3d3c94573 you said that sing eval_ function is not a bad idea?​

PS.

Is this the Doors Server backend project?

https://github.com/domoran/DriveDOORS

 

Three downsides of using eval are:

    --having to program using escape characters

    --increased complexity of tracking down bugs in source code

   --Getting the right context can be challenging

 

It might be said there are ways to deal with each of these downsides -- but that is another downside i.e.,  finding solutions to the downsides

Re: Is it good to create service whih use _eval?
Mathias Mamsch - Wed Jul 13 05:41:32 EDT 2016

Dinio - Wed Jul 13 01:48:52 EDT 2016

Yes,@Mathias

there are a lot of pitfalls but our client does might not want to use Sodius because of the license policy.($$$) But I am wondering what is the power of this Sodius can it read tables, OLE objects etc.?

Using such eval_ compatible service will help us in a lot of cases , but we can still rely on old Doors services with installation scripts on the Backend and so on , as well as OSLC services which has a lot of bugs and make their usage hard.

So, @Mathias Mamsch ad07d6e1-5bea-4d69-8513-47a3d3c94573 you said that sing eval_ function is not a bad idea?​

PS.

Is this the Doors Server backend project?

https://github.com/domoran/DriveDOORS

 

We use Sodius here at Continental for a similar integration project. We use the MD Workbench Server as Backend offering webservices to access DOORS and other systems. A lot of the hard tasks are eased up by this (reliable fast connection handling to DOORS, OLE Handling,  RTF <-> XHTML conversions) and their connector has commands for most of the tasks you want to do (writing attributes, creating links, external links, etc.).  With the MD Workbench Server you get a way to handle synchronous and asynchronous web services with a progress protocol for the asynchronous web services, a job queue and an easy way to deploy services. Last but not least you should not underestimate commercial support for adapting to future DOORS versions, etc. So all in all it is an impressive package - the question is probably if you need all that and if your customer is willing to spend money for the license fees. 

So much for now for the Sodius ...

Regarding https://github.com/domoran/DriveDOORS: 

I started up with the DriveDOORS project, but I really do not find the time to get it even to an alpha stage. The idea of that project was to supply a generic backend to DOORS (server or client based) which would allow to create DXL scripts that can handle data I/O for DOORS in an efficient way. It never became more than a prototype and there is probably not a lot of code to use here. 

But since I know that there are many people / organizations facing the same problem I am willing to contribute to an open source project for a DOORS Backend Server, if it is actively driven by somebody else. 

Regarding eval_: 

There is nothing wrong with eval_. Of course if you have a long running server process, then you will have to think a lot about memory handling, since garbage can easily pile up in memory making your server process slower and slower. You need a memory leak free and stable way to perform I/O with your outside java process. You need process handling, since a started DOORS client is bound to a specific DOORS user. If you are worried about security you need a safe way to start DOORS processes without the password being visible on the commandline. If you want to do massive parallel access to DOORS you need to worry about the User Directory being locked for a short period during login, making other logins at the same time fail. Etc. 

Regards, Mathias

Re: Is it good to create service whih use _eval?
Mathias Mamsch - Wed Jul 13 05:44:53 EDT 2016

DOORSHAM - Wed Jul 13 05:25:10 EDT 2016

Three downsides of using eval are:

    --having to program using escape characters

    --increased complexity of tracking down bugs in source code

   --Getting the right context can be challenging

 

It might be said there are ways to deal with each of these downsides -- but that is another downside i.e.,  finding solutions to the downsides

I don't see that. Normally from eval_ you will use 'include' statements inside your eval to avoid escaping and run your tested code. If it runs outside eval it will run inside eval with very few technical differences.

Re: Is it good to create service whih use _eval?
AlexTidmarsh - Wed Jul 13 17:38:11 EDT 2016

Mathias Mamsch - Wed Jul 13 05:44:53 EDT 2016

I don't see that. Normally from eval_ you will use 'include' statements inside your eval to avoid escaping and run your tested code. If it runs outside eval it will run inside eval with very few technical differences.

I agree.


I have spent the last four years (or so) developing code that interacts with DOORS from Delphi (Borland/Embarcadero/etc) which is entirely based on the principle of using the eval_() perm.   I can wholly recommend its use.

The more difficult problem to solve (which has earned me a lot of money in those four years) is in creating and maintaining a mechanism that makes the execution of "DOORS as a service" and conversely "Delphi as a service for DOORS" relatively trivial to use.   But the potential power and versatility unleashed by enabling it is phenomenal.

Regards
Alex

Re: Is it good to create service whih use _eval?
Wolfgang Uhr - Thu Jul 14 09:04:33 EDT 2016

Mathias Mamsch - Wed Jul 13 05:41:32 EDT 2016

We use Sodius here at Continental for a similar integration project. We use the MD Workbench Server as Backend offering webservices to access DOORS and other systems. A lot of the hard tasks are eased up by this (reliable fast connection handling to DOORS, OLE Handling,  RTF <-> XHTML conversions) and their connector has commands for most of the tasks you want to do (writing attributes, creating links, external links, etc.).  With the MD Workbench Server you get a way to handle synchronous and asynchronous web services with a progress protocol for the asynchronous web services, a job queue and an easy way to deploy services. Last but not least you should not underestimate commercial support for adapting to future DOORS versions, etc. So all in all it is an impressive package - the question is probably if you need all that and if your customer is willing to spend money for the license fees. 

So much for now for the Sodius ...

Regarding https://github.com/domoran/DriveDOORS: 

I started up with the DriveDOORS project, but I really do not find the time to get it even to an alpha stage. The idea of that project was to supply a generic backend to DOORS (server or client based) which would allow to create DXL scripts that can handle data I/O for DOORS in an efficient way. It never became more than a prototype and there is probably not a lot of code to use here. 

But since I know that there are many people / organizations facing the same problem I am willing to contribute to an open source project for a DOORS Backend Server, if it is actively driven by somebody else. 

Regarding eval_: 

There is nothing wrong with eval_. Of course if you have a long running server process, then you will have to think a lot about memory handling, since garbage can easily pile up in memory making your server process slower and slower. You need a memory leak free and stable way to perform I/O with your outside java process. You need process handling, since a started DOORS client is bound to a specific DOORS user. If you are worried about security you need a safe way to start DOORS processes without the password being visible on the commandline. If you want to do massive parallel access to DOORS you need to worry about the User Directory being locked for a short period during login, making other logins at the same time fail. Etc. 

Regards, Mathias

> But since I know that there are many people / organizations facing the same problem I am willing to contribute to an open source project for a DOORS Backend Server, if it is actively driven by somebody else. 

 

But all this people allways have the same problem. Typical firewall restrictions or local admin restrictions make it impossible to join such a project by using the licence of their own employees. So they allways have to provide a private doors installation to join this project. And you know the prices for that licences and so on.

 

I do not pay more than $ 4.000 to join such a project.

 

May be that some employers are able to support such a project. For example, if someone in usa or australia has a licence, someone can use this licence here if it is night there?